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Abstract 

A new method for analyzing relational specifications is described. A prop- 
erty to be checked is cast as a relational formula, which, if the property 
holds, has no finite models. The relational formula is translated into a boo- 
lean formula that has a model for every model of the relational formula 
within some finite scope. Errorsin specifications can usually be demon- 
strated with small counterexamples, so a small scope often suffices. The 
boolean formula is solved by an off-the-shelf satisfier. 

T he satisfier requires that the boolean formula bein conjunctive normal 
form (CN F). A naive translation to CN F fails (by exhausting memory) for 
realistic specifications. This paper presents a preliminary design of a com- 
piler that overcomes this problem, by exploiting typical features of the rela- 
tional formulae that arise in practice. Initial experiments suggest that this 
method scales more readily than existing approaches and will be able to find 
more errors, in larger specifications. 



Keywords Software design analysis, formal specification, object model, Z, 
relational calculus, model finding, boolean satisfaction, WalkSAT, N itpick. 



1 Introduction 

Two views are central in software design. Thee/entview isconcerned with 
which events may occur during execution of the system, and their ordering 
patterns. The object configuration view isconcerned with which objects exist 
and their relation ships to one an other. Even though these views are not 
disjoint- as events occur, configurations change- it is often useful toex- 
aminethem independently. 

M ost formal specification languages have been developed with primarily 
one of these views in mind: the event view for CSP, Statech arts and Lotos; 
the object configuration view for Z, VDM and Larch. Object oriented 
methods, such asO M T, Fusion and Syntropy, typically advocate the con- 
struction of a model for each view: the "dynamic model" for the event view 
(typically expressed as a Statech art) and the "static model" for the object 
configuration view (typically expressed as an entity-relationship diagram). 

The analysis of event views is well supported by tools: in addition to simu- 
lators, there are now model checkers that can exhaustively analyze huge state 
spaces. bject configuration views, in contrast, are poorly supported. Ex- 
isting automated tools offer only shallow syntactic checks of the description, 
and rarely expose problems in the software design itself. 

This disparity is particularly remarkable given the centrality of object con- 
figurations Theeventview is sometimes dominant (for example, in thede- 
sign of protocols and process control systems), but usually plays a subsidiary 
role. Take a glance at an influential book on design patterns [G 455], and 
note the proportion of diagrams that describe object configurations. 

Nitpickisan attempt to redress this imbalance. Given a constraint describ- 
ing a set of object configurations, Nitpickcan generate in stances satisfying 
the constraint. It can check that declared constraints have intended conse- 
quences, by searching for instances that satisfy one constraint but not an- 
other. N itpick also accepts descriptions of operations that describe transi- 
tions from one configuration to another, and can simulate these, and check 
a variety of their properties, such as whether an operation preserves a con- 
straint. 

Thecurrent implementation of N itpick works by explicit enumeration. 
Using a variety of mechanisms to prune the search tree, it can analyze 
enormous configuration spaces. The tool has been used successfully to find 
flaws in a number of small designs including a published draft of a mobile 
internet routing protocol [Ng97, JNW97]. Even small designs, however, 
tend to have huge configuration spaces. Indeed, this is perhaps why analysis 
of object configurations has not attracted the same attention as the analysis 
of state machines. A relation over a domain of 3 elements has 512 possible 
values; adding a single such relation to a specification thus increases the 
space by 3 orders of magnitude. 



This paper describes a new method for analyzing descriptions of object 
configurations. Section 2 presents a toy example that conveys the flavour of 
the specification notation; Section 3 compares the notation to popular no- 
tations. Section 4 demonstrates a N itpick analysis of the example. 

Section 5 explains how simulation and checking can both be reduced to 
model finding. Section 6 articulates the hypothesis that most errors can be 
illustrated with small counterexamples. 

Section 7 gives the intutions behind the new method. Sections 7 to 16 are 
the core of the paper; they present the structure of the compiler: the se- 
quence of representations and their respective transformations. 

Section 17 gives some performance results that compare the new method to 
our previous explicit method. Section 18 and 19 discuss related work and 
future plans. 

2 Relational Notation: NP 

ur notation, N P, is roughly a subset of Z [Spi92]. A reference manual 
[J D 96b] describes the notation in detail. Here, we explain its basic elements 
with a toy example. 



[Ph, Num] 

Switch = [ 
called : Ph <-> Num 
const net : Num -> Ph 
conns : Ph <-> Ph 
I 
conns = called ; net ] 

Join (p : Ph ; n : Num) = [ 
Switch 
I 

p in dom called 
n not in ran called 
called' = called U {p -> n} ] 

JoinOK(p : Ph ; n : Num) :: [ 
Switch | Join (p, n) and inj conns => inj conns' 



Figure 1: NP specification of ESS 



The Extremely Simple Switch (ESS) connects telephones by maintaining 
two relationships: called, which maps phones to numbers, and represents 
ongoing phone calls, and net, a constant relationship that maps numbers to 
the phones they name. When (pi, n) belongs to called, phone pi has an 
active connection to the number n; when (n, p2) belongs to net, p2 is the 
phone specified by the number n. The composition of called and net is a 
relation connsthat associates phones that are connected; it would include, in 
this case, the pair (pi, p2). 

Part of a (faulty) specification for ESS isshown in Figure! Thefirst line 
declaresPh and N urn to be primitive types. The schema Switch that follows 
declares the three state components with an accompanying constraint that 
serves to define conns- redundant and introduced only for the convenience 
of later expressing certain properties- in terms of the other two. 

Theform of thearrow in a declaration indicates the kind of relation. Thus 
called is an arbitrary relation, allowing the modelling of conference calls in 
which a phone has called more than one number at a time, but net is a 
function. 

Switch defines a set of configurations Entity relationship diagrams can be 
used for the same purpose, but are not as expressive. The diagram of Figure 
2 corresponds to the declarations of Switch, but does not express the con- 
straint amongst the three relations. 
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Figure 2: ER diagram corresponding to Switch schema of Figurel 



The schema Join specifies an operation in which anew party isadded to a 
call. The parameter pisthephoneat which thejoin isperformed; it iscon- 
strained to be already making a call. Theparameter n isthenew number 
being called, and isconstrained not to be already called. The effect of the 
operation is given by the last constraint. Here, the primed instance of the 
variable called denotes the value of the state component after the operation; 
it thus asserts that the operation adds the pair (p, n) tothecalled relation. 
The net relation, having been declared in the imported schema Switch to be 
constant, does not change; it is as if the assertion 

net' = net 

were included. Beyond this, there are no implicit frame conditions. In fact, 
the change in called will generally require a corresponding change in conns 

The third schema, J oinOK, is a claim. It is not part of the specification 
proper. Rather, it asserts a property of the specification: that if the relation 
conns is injective prior to execution of a join, it will be injective afterwards 
too. If conns is not injective, there is a call involving two phones acting as 
callers; for billing reasons we prefer to avoid this situation, and construct all 
conference calls with a single caller. 



3 Why Relational Specification? 

This style of specification was pioneered by the developers of the Z specifi- 
cation language. For readers familiar with other notations, we shall explain 
briefly what features of the relational notation make it, in our opinion, a 
more suitable notation for describing object configuration views. 

The principal difference between our language, N P, and Z isthat N P is 
first-order: its data structures are simple relations, and it does not admit, for 
example, relations between relations. While Z is based on set theory, N P is 
based on the relational calculus. Z's extra power makes it less tractable; N P 
gains much in tractability for a relatively small reduction in expressiveness. 



Theformal specification languagesVDM and Larch have much in common 
with Z. Their data structures, however, are not based on set theory but 
rather on a collection of data types each with its own axiomatization. In a 
sense, N P is less abstract, since all data structures are encoded as graphs. But 
for describing configurations, graphsareso natural that bias is rare, and 
more abstract types are not needed. 

Theinput languages of model checkers, such asSMV's assignment lan- 
guage, M urphi's Unity-like language and SPIN'sPromelatend to have 
weak support for data structures, and do not provide primitives for com- 
posing relations and applying functions. They also tend not to support im- 
plicit specification fully, in which the result of an operation is defined by an 
assertion relating the variables of pre- and post-states, rather than by an ex- 
plicit assignment. 

bject-oriented methods, such asU M L, M T, Fusion and Syntropy, pro- 
vide graphical notationsfor describing object models These are extremely 
weak, and allow only the most elementary constraints between relations 
(such as that one isa subset of another) to be expressed. Various textual an- 
notation languages have been designed, most recently U M L's Object Con- 
straint Language (OCL) [IBM 97], which originated in the constraints of 
Syntropy. OCL is very similar to N P, although it does not have a formal 
semantics and does not appear to be able to express transitive closure. I ts 
syntax looks very different from N P's however; it makes heavy use of scalar 
quantifiers in place of relational operators, and has no structuring mecha- 
nism akin toschemas. 

In practice, object models are much less powerful than relational models, 
since they are usually interpreted in terms of implementation constructs. So 
subset, for example, is usually construed as subclass Since standard object- 
oriented languages do not allow objects to migrate between subclasses, this 
means that the members of a subset can not change. Unlike in N P, there- 
fore, onecould not introducea set Callers that isa subset of Ph, corre- 
sponding to the phones making calls, since this set changes over time and 
thus can not be a subclass. 

4 Nitpick in Action 

Let's see what Nitpick can do with a specification. It basically offers two 
features: simulation and checking. Simulating a state schema produces in- 
stances of the state that satisfy the given constraints Instructing N itpickto 
simulate Switch in Figure 1, for example, will cause it to output the rather 
uninteresting case: 

called: {} 
net:{} 
conns: {} 

Simulating an operation schema produces sample transitions. For Join, Nit- 
pick will produce 



p: P2 

n: N2 

called: {P2->N1} 

net:{} 

conns: {} 

called': {P2->N1,P2->N2} 

conns': {} 

exposing a simple flaw: we have allowed active calls to numbers that are not 
associated with phones. 

Checking a claim also causes in stances to be generated. The claim J oinOK is 
about an operation, and the instances will thus be transitions. These in- 
stances, however, are counterexamples: they correspond to cases that show 
the property to be invalid. ForJoinOK, Nitpick will attempt to find a tran- 
sition ofjoin from a state i n which connsisinjectiveto a statein which it is 
not, such as 

p: P2 

n: N2 

called: {PI ->N1 ,P2->NO} 

net:{Nl->P2,N2->P2} 

conns: {PI ->P2} 

called': {PI ->N1 ,P2->NO,P2->N2} 

conns': {PI ->P2,P2->P2} 

This counterexample demonstrates (at least) two flaws with the specifica- 
tion. In thepre-state, called maps a phone to a number that is not in the 
domain of net; that is, there is an active call to a number not associated with 
a phone. The net function is not injective- there are two numbers mapped 
to the same phone; either this must be ruled out, or the definition of the 
operation must take it into account. 

5 Specification Analysis as Model Finding 

Both simulation and checking amount to the same problem: solving a rela- 
tional formula. Solving a formula means finding an assignment to its vari- 
ables that makes the formula true; such an assignment is a model of the for- 
mula. The formula is extracted from the specification by simply undoing 
the syntactic shorthands; fromJoinOK, for example, Nitpick obtains the 
formula 

conns = called ; net 

and conns' = called' ; net 

and p in dom called 

and n not in ran called 

and called' = called U {p -> n} 

and inj conns 

and not inj conns' 

A coupleof features of this formula are worth noting. First, notethatin 
translating a claim, the formula is negated: for a claim, an assignment for 



which the formula is false is required, namely a model of the formula's ne- 
gation. Second, since a state invariant constrains the states both before and 
after an operation, the inclusion of the schema Switch bringstwosubfor- 
mulae: one on theunprimed variables, and one on the primed variables. 
Third, observe the structure of the formula as a whole: aconjunction of 
(mostly positive) elementary subformulae. This is typical, and our method 
exploits it. 

The free variables of such a formula may denote scalars, sets or relations A 
set of type declarations, not shown above, is associated with each formula. 
For example, the variable pis constrained to be a scalar of type Ph. In con- 
structing an assignment, therefore, we must first choose sets of values for the 
primitive types. Our types are uninterpreted, so we use symbolic names for 
the elements: pi, p2, p3 for Ph, say. Given this set of 3 values for Ph, the 
variable p can take on 3 possible values. The variable conns can take on 512 
values: there are 9 possible connections from a phone to a phone, each of 
which is present or absent. 

6 The Small Scope Hypothesis 

Every relational formula has infinitely many possible assignments. To make 
a finite search possible, we place an artificial bound by limiting the number 
of atoms in each type. A scope S is a mapping from the type names of a 
specification to natural numbers; S(t) is interpreted as a bound on the num- 
ber of atoms in the type t. We say than an assignment is within a scope, or 
that a scope admits an assignment, when the values of the variables in the 
assignment can be constructed using no more atoms than the scope allows. 

1 n our example, to consider only assignments involving at most 3 phones 
and 2 numbers, we would choose S(Ph) =3 and S(Num) =2. We shall say 
that a search has a scope of S when it considers only assignments within S. 
Sometimes we shall refer loosely to a "scope of 3", which simply means that 
S(t) = 3 for every type t. 

The problem of finding models of relational formulas is highly intractable, 
since the number of assignments grows so rapidly with both the scope and 
the number of variables. For a scope of k, a relation can havek edges and 
thus 2to the power k values The size of the space is the product of the 
number of values of each variable, so for v relational variables, there may be 

2 to the power k v assignments. Increasing the scope from kto k+1 thus 
increases the space by 2 v . 

Itthereforeseemsveryunlikdythatamethod based on search will be able 
to handle large scopes. This, perhaps, is why research on analysis of lan- 
guages such asZ and VDM has focused almost exclusively on syntactic and 
not semantic methods. 

The hypothesis underlying N itpick is a controversial one. It is that, in prac- 
tice, small scopes suffice. In other words, most errors can be demonstrated 
by counterexamples within a small scope. Thisisa purely empirical hy- 



pothesis, since the relevant distribution of errors cannot be described 
mathematically: it is determined by the specifications people write. 

ur hope is that successful use of the N itpick tool will justify the hypothe- 
sis. There is some evidence already for its plausibility. In our experience 
with N itpick to date, we have not gained further information by increasing 
the scope beyond 6. 

A similar notion of scope is implicit in the context of model checking of 
hardware. Although the individual state machines are usually finite, the de- 
sign is frequently parameterized by the number of machines executing in 
parallel. This metric is analogous to scope; as the number of machines in- 
creases, the state space increases exponentially, and it is rarely possible to 
analyze a system involving more than a handful of machines. Fortunately, 
however, it seems that only small configurations are required to find errors. 
The celebrated analysis of the Futurebus+ cache protocol [C+95], which 
perhaps marked theturning point in model checking's industrial reputa- 
tion, was performed for up to 8 processors and 3 buses. The reported flaws, 
however, could be demonstrated with counterexamples involving at most 3 
processors and 2 buses. 

7 Intuitionsfora Boolean Method 

For a finite scope, a relational formula can be translated into an equivalent 
boolean formula. The idea is simple. We represent relations as boolean ma- 
trices, each bit corresponding to a possible edge in the relation. A solution 
to the boolean formula is translated into a solution to the relational formula 
by constructing the relations whose edges are present or absent according to 
the values of the bits 

The translation can be performed compositionally. In general, a relational 
term istranslated into a matrix of boolean formulae. For each relational 
variable, we introduce a matrix of boolean variables; each term isthen 
translated by composing the translations of itssubterms. 

Suppose, for example, that we have translated a term p into a matrix [p], 
and a term q into a matrix [q]. The element in theith row and thejth col- 
umn of [p], which we write [p] y , is a boolean formula that is interpreted as 
being true when p maps theith element of its domain type to thejth ele- 
ment if its range type. The translation of the term pnq is given by 

[P n q]ij = [p]ij a [p]ij 

since an edge is in the intersection of two relations when it is in both rela- 
tions. For each of the relational operators there is such a rule. 

Elementary relational formulae are translated into boolean formulae. The 
rule 

[p c q] = A u [p]u => [q]u 

for example, states that a relation p is a subset of a relation q when there is 
an edge in q corresponding to every edge in p. 



Sets and scalars are treated as degenerate relations. A set-valued term is 
translated into a vector of boolean formulas; the rules for set intersection 
and subset are just I ike the rules shown above, but with one index omitted. 
Scalars are represented as singleton sets; when a scalar variable is translated, 
a side-condition is created that asserts that exactly one of the elements of the 
set is present. This side condition is conjoined with the formula obtained 
from translation right at the end. Similar side conditions are generated to 
express properties of relations given in their declarations: that a relation is a 
function, or is total, etc. 

N itpick is thus, in essence, a compiler. Various syntax and type checks are 
applied to the specification. Given the user's selection of a schema to simu- 
late or a claim to check, a relational formula is extracted. This formula is 
then compiled into a boolean formula, which is then presented to a boolean 
satisfier. By maintaining the appropriate associations between the relational 
variables and the boolean variables, the tool can then translate boolean as- 
signments back into relational assignments. 

Note that the major compilation step- obtaining the boolean formula- is 
scope dependent, since the dimensions of the boolean matrices are deter- 
mined by the number of elements in the basic types. Each time the user 
changes the scope, theformula must be recompiled into a new boolean 
formula, which is then presented to the solver. 

From a design point of view, it seems desirable to implement boolean for- 
mulae with an abstract data type. The translator would then call operations 
on the type to construct compound formulae rather than meddling directly 
with their syntax. Thesolver itself might be encapsulated within theabstract 
type, as an operation of type 

BooleanFormula -> BooleanAssignment. 

To change the representation of formulae, or to choose a different solver, 
we would then need only to replace this abstract type. Using subclassing, 
and perhaps the Factory design pattern [G+95], we could even support 
these selections at runtime. 

Were thisscheme viable, our paper would be very short. Unfortunately, 
however, it turns out that the choice of solver is not a concern that can be 
easily separated from the rest of the design. Few solvers will accept a boo- 
lean formula with an arbitrary structure; the ones that appear to be most 
efficient for our problem requiretheformulatobein conjunctive normal 
form. A naive translation produces such huge formulae that the translator 
seizes up on even tiny examples. 
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Figure 3: Architectureof N itpick 
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There are three basic tricks Nitpick uses to reduce the size of the formula. 
Thefirst isto decompose it into a disjunction of formulae, each itself in 
conjunctive normal form. Rather than attempting to construct a single huge 
formula, these formulae are solved independently; a solution toanyoneisa 
solution to the formula as a whole. The second isto introduce temporary 
variables; this is a tradeoff, since although it can reduce the formula size 
substantially, it can also make the formula harder to solve. Thethird isto 
find opportunities for decomposition of a formula into a disjunction in 
which several of thedisjunctscan be discarded. 

Each of these tricks exploits the structure of the relational formula. The de- 
composition into a disjunction follows natural cases in the specification it- 
self. The introduction of temporaries is applied only when translating rela- 
tional terms that tend to cause a blowup. Finally, the discarding of disjuncts 
relies on observing certain symmetries in the structure of the relational for- 
mula. 

Loss of modularity is perhaps inevitable. After all, it would be foolish not to 
exploit the structure of the problem at hand to the greatest extent. A naive 
translation yields a boolean formula in which this structure has been lost. It 
might, of course, be possible to recover it, but it makes more sense to ex- 
ploit the structure where it is manifest: in the translation process itself. 

8 Structure of the compiler 

Nitpick isstructured likea compiler (Figure3). In thefirst phase, thespeci- 
fication is parsed and superficial syntactic checks are performed. Schema 
references are expanded, and for each schema or claim a relational formula 
is obtained, represented as an abstract syntax tree with symbol tables hold- 
ing, for example, type information about variables. These formulas are from 
now on treated independently; a series of translations is applied to each. 

In the second phase, each relational formula is converted to disjunctive 
normal form. This is a purely logical transformation that treats the elemen- 
tary relational formulae as uninterpreted. The result of this phase is a set of 
sets of elementary relational formulae. From hereon, each set is treated as 
an independent problem, from which a single boolean formula will be gen- 
erated. These problems are translated and then solved in turn. 

In thethird phase, therelational subformulae themselves are compiled into 
a more primitive relational calculus with fewer operators. In the fourth 
phase, temporary variables are introduced and opportunities for symmetry 
breaking are identified. Finally, in thefifth phase, the boolean formula is 
generated, in conjunctive normal form. Thisformula isthen presented to 
the solver. Either the solver fails to find a solution (usually but not necessar- 
ily because the formula isunsatisfiable), or it returns an assignment to the 
boolean variables that makes the boolean formula true. From this assign- 
ment, an assignment to therelational variables is easily constructed (using a 
mapping generated as a byproduct of the translation), and is displayed for 
the user. 
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Type checking is currently performed after the third phase, on the interme- 
diate language. This has the advantage of greatly simplifying the type 
checker, but it does result in more cryptic error messages than would be 
obtained by analyzing the source code directly. In a production version of 
the tool, it would be better not to postpone type checking. 

Subsequent sections elaborate on these phases in turn. 

9 Relational Disjunctive Normal Form 

The motivation for translating into DN F istwo-fold: to decompose the 
checking problem, so that checking can be performed more efficiently, and 
to provide more useful feedback to the user. 

A simplified version of the input language is given in Figure4. Weignore 
the schema structuring, which affects only the design of the front end, and 
assumethatadaim to be checked or schema to be simulated has been ex- 
panded into a relational formula. Thisformula language is essentially a first- 
order subset of Z. In the input language, the operators are written in ascii 
form; they appear in ascii hereto make the distinction between the input 
language and the intermediate language (discussed later) clearer. 

Disjunctive normal form (DN F), which we shall refer to as relational DNF 
(to avoid any confusion with the normal form we discuss later on boolean 
formulae) isa subset of the formula language, in which negation can only be 
applied to elementary formulae, and only formulae not containing disjunc- 
tions may be conjoined. In other words, the formula is represented as a 
disjunction of conjunctions of literals, where each literal is an elementary 
relational formula or its negation. 

Putting an arbitrary formula in normal form can cause an exponential 
blowup. In practice, though, our specifications rarely generate formulae 
with more than a handful of disjuncts. Disjunction arises primarily from 
two idioms. 

In operation specifications, disjunction arises from case splitting. Suppose 
for example, our Join operation (Figure 1) is to handle the case, not previ- 
ously specified, in which the number bang called has already been called. 
The operation might then be written: 

Join2 (p : Ph ; n : Num) = [ 

Switch 
I 

p in dom called 

((n not in ran called => called' = called U {p -> n}) 

and (n in ran called => called' = called)) 
] 

which says that if the number has already been called, the operation has no 
effect; otherwise the behaviour is as before. When asked to simulate this 
operation, N itpick will convert the specification to D N F, obtaining two sets 
of dementary rdational formulae, thefirst corresponding to one case: 
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formula :: = 
formula and formula 
| formula or formula 
| not formula 
| formula => formula 
| elemformula 

elemformula :: = 

expr <= expr relation or set subset 

expr < expr relation or set proper subset 

| expr in expr set membership 

| expr = expr relation, set or scalar equality 

expr :: = 

expr U expr union of sets or relations 

expr & expr intersection of sets or relations 

expr \ expr difference of sets or relations 

expr (+) expr relational override 

expr ; expr relational composition 

expr ~ relational transpose 

expr . expr relational image or function application 

expr + transitive closure 

expr * reflexive and transitive closure 

dom expr domain of a relation 

ran expr range of a relation 

expr <: expr domain restriction 

expr :> expr range restriction 

expr <; expr domain subtraction 

expr ;> expr range subtraction 

Un universal relation constant 

Id identity relation constant 

{ } empty set or relation constant 

{ expr, ..., expr } set constructor 

{ expr -> expr, ...} relation constructor 

Figure 4: A syntax of the formula sublanguage of NP 



conns = called ; net 
p in dom called 
not n in ran called 
called' = called U {p -> n} 

and the second corresponding to the other case: 

conns = called ; net 
p in dom called 
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n in ran called 
called' = called 

These are subsequently treated as separate problems; thetools will attempt 
to find a model for the first, and then for the second. As we shall see later, 
avoiding top-level disjunction hasa dramatic effect on performance. 
M oreover, the results obtained by this decomposition are exactly what the 
user would expect, since the two subproblems correspond to separate cases 
in the specification itself. 

Thesecond idiom from which disjunction arises occurs with in a claim. The 
specifier might assert that an operation satisifestwo properties. For example, 
we might want to say not only that J oi n preserves the invariant that conns is 
injective, but that it also preserves the invariant that no phone is both 
making and receiving a call at once. This latter invariant can be defined in 
its own schema 

OneRole = [Switch | dom conns & ran conns = {}] 

and we can then formulate the elaborated claim as 

JoinOKl (p : Ph ; n : Num) :: [ 
Switch | Join (p, n) and inj conns and OneRole => inj conns' and OneRole'] 

This claim is, incidentally, weaker than the combination of the old claim 
(JoinOK) and a separate claim for maintenance of the new invariant, such as 

JoinOK2 (p : Ph ; n : Num) :: [ 
Switch | Join (p, n) and OneRole => OneRole'] 

since, by asserting that the conjunction of the invariants is maintained, its 
hypothesis includes both invariants; one invariant may thus contribute to 
the preservation of the other. 

T he result of DNF conversion of JoinOKl is two cases, one for violation of 
the first invariant: 

conns = called ; net 

p in dom called 

not n in ran called 

called' = called U {p -> n} 

inj conns 

dom conns & ran conns = {} 

not inj conns' 

and another for violation of the second: 

conns = called ; net 

p in dom called 

not n in ran called 

called' = called U {p -> n} 

inj conns 

dom conns & ran conns = {} 

not dom conns & ran conns = {} 
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Again, checking these separately is a big performance win, and gives useful 
information to the user: namely which invariant is broken. 

Elaborating both the claim and the operation, so that the claim is now 

JoinOK3 (p : Ph ; n : Num) :: [ 
Switch | Join2 (p, n) and inj conns and OneRole => inj conns' and OneRole'] 

would yield four analysis problems. When the checker finds a counterex- 
ample, it will indicate which branch of the operation violates the property 
and which property is violated. 

Technically, the consequent of the implication of an apparently simple 
claim such asJoinO K2 is actually a conjunction, si nee the schema reference 
neRole is expanded into the conjunction 

conns = called ; net 

dom conns & ran conns = {} 

A naive translation would yield a case such as 

conns = called ; net 
p in dom called 
not n in ran called 
called' = called U {p -> n} 
dom conns & ran conns = {} 
not conns = called ; net 

which isobviously not satisfiable. To avoid generating such spurious cases, 
thetool performs some basic simplifications during conversion to DNF, so 
that no conjunct contains both an elementary formula and its negation. 

10 Intermediate Relational Language 

The second major transformation is applied at the level of the relational 
operators, within the elementary subformulae. Its motivation isto simplify 
the code of the subsequent transformations. T he result of this step, which 
can be viewed as an intermediate language, is a formula with the same 
structure, but with relational expressions expanded to compensate for a 
more frugal repertoire of relational operators. 

The operators of this intermediate language are listed in Figure 5. They in- 
clude the three set-theoretic operators (union, intersection and difference) 
that can be applied to sets and relations; thetwo quintessentially relational 
operators (composition and transpose); and three constants (the universal, 
identity, and empty relations). These, along with the equality operator for 
obtaining formulae from terms, together constitute a basic relational lan- 
guage equivalent to Tarski's relational calculus [Giv88, Tar41]. This lan- 
guage is as expressive as first-order predicate logic (so long as we permit 
definition of projection functions so that tuples can be constructed), and is 
thus undecidable [Sch79]. 

The language includes, additionally, the transitive closure operator, which 
extends its expressiveness, and is indispensable in practice. We also add two 
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formula :: = 




expr = expr 


equality 


| expr e expr 


subset 


expr :: = 




Id 


identity relation constant 


| Un 


universal relation constant 


1 o 


empty relation constant 


| expr u expr 


union 


| expr n expr 


intersection 


| expr \ expr 


difference 


| expr ; expr 


relational composition 


| expr ~ 


transpose 


| expr + 


transitive closure 


| expr <: expr 


domain restriction 


| dom expr 


domain 



Figure 5: Intermediate Language 



operators that add nothing in a formal sense, but which allow more efficient 
generation of boolean formulae. They are the domain operator, which takes 
a relation to the set of elements that it maps, and domain restriction, which 
given asetand a relation, produces the subrelati on whose pairs have first 
elementsin theset. We view these as the 'bridging operators' that connect 
relations and sets 

The language's typing rules and semantics are given in Figures6 and 7. M 
and E arethemeaningfunctionsfor formulae and expressions respectively; 
C maps a type to its carrier set. Each operator is given a meaning in terms of 
naive set theory. A relation is viewed as a set of pairs; the union of two rela- 
tions thus becomes, for example, theunion of the two sets of pairs. A set is 
not viewed directly as a set, but rather as a relation whose range type is the 
special type Unit, consisting of exactly one atom unit. To encode a set with 
this representation, we simply construct a relation that includes the pair (e, 
unit) for each element e of the original set. 

The constants (universal, empty and identity) are to be considered as in- 
dexed sets of constants, each with a different type. So in an expression such 
as(Un n p), the appropriate instance of the constant will be chosen, whose 
type matches the type of the relation p. 

W e chose to represent sets as relations because it corresponds to the natural 
boolean representation of a set as a bit vector. T he result is a cleaner back- 
end, in which set-theoretic operators can be treated identically for the set 
and relation cases. 



17 



Id :T<^T 



Un : S<^T 



: S^T 



p: 


S^T, 


q: S <-> T 




puq 


: S<-h>T 


p: 


S^T, 


q: S <-> T 




pnq 


: S<-h>T 


p: 


S^T, 


q: S <-> T 




p \ q : 


S^T 


p: 


S^T, 


q:T<->V 



p ; q : S <-> V 

p: S <-> T 
p~ : T <-> S 

p:T^T 



p+ : T^T 

p: S <-> Unit, q: S <->T 
p <: q : S <-> T 

p: S <-> T 
dom p : S <-> Unit 



Figure6: Typing rulesfor the intermediate language 



A more elegant treatment of sets [SS93], which we have used to justify re- 
ductions in our explicit checker [J J D 97], represents the set s as the relation 
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corresponding to thecross product of sand theuniversal set. In this scheme, 
no additional operators are required: the domain of a rdation, for example, 
is obtained by composing the rdation with theuniversal rdation. In prac- 
tice, however, it has a major disadvantage. The source language expression 



where sis a set and risa rdation, would be translated into the intermediate 
language expression 

Snr 

where S is the rdation corresponding to (sx Un). What is the type of S in 
this expression? Its domain type will be the type of the dements in the 
original sets I ts range type, however, must be the type of the range of r. 
Since the type of sin the source expression places no constraint on the range 
type of r, we must equally allow 

Snq 

where q has a different range type from r. The rdation S must therefore be 
regarded as polymorphic in its range type. This complicates the backend of 
the compiler far more than the addition of a few extra operators to the in- 
termediate language. 

Type declarations in Nitpick, as in Z, may involve implicit constraints. A 
rdation may be declared to be a function, or to be total, for example. These 
constraints are translated into the operators of the intermediate language. 
For example, the assertion that the rdation p is a function can be expressed 
as 

p~ ; p c Id 

Each such dementary formula extracted from a declaration is conjoined to 
every dausein theDN F representation, since type constraints apply in 
every case. 

For example, the clause 

conns = called ; net 
conns' = called' ; net 
p in dom called 
n not in ran called 
called' = called U {p -> n} 
inj conns 
not inj conns' 

with type declarations 

p: Ph; n: Num; called: Ph <-> Num; net: Num -> Ph; conns, conns': Ph <-> Ph 

is translated into 

conns = called ; net 
conns' = called' ; net 
p e dom called 
-i n e dom called~ 
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called' = called u (p <: (n <: Un)~) 
conns ; conns~ c Id 
-i conns' ; conns'~ c Id 

with type declarations 

p: Ph <-> Unit; ; n: Num <-> Unit; 

called: Ph <-> Num; net: Num <-> Ph; conns, conns': Ph <-> Ph 

and additional type constraints 



p ; 


p~ 


eld 




— 1 


P 


= 


n ; 


n~ 


eld 




— 1 


n 


= 


net~ ; 


net c 


Id 









11 An Interlude: Boolean Conjunctive Normal Form 

T o motivate the last two stages of compilation, we must take a short digres- 
sion to explain the normal form in which the boolean formula is finally cast, 
si nee its structure and properties motivate the design of these stages. 

The boolean formula is represented in conjunctive normal form, that is, as a 
conjunction of disjunctions. A formula is a set of clauses; a clause is a set of 
literals; a literal is a boolean variable or its negation. H ere are some examples 
of formulae and their representation in CNF: 

aAb {{a},{b}} 

a v b {{a, b}} 

a => b {{-a, b}} 

a ^ b {{-a, b}, {a, -b}} 

In a compositional translation to conjunctive normal form, we will need to 
know, given two formulae F and G in CN F, how to create the CN F for- 
mula for F aG, F vG, — iF , etc. Conjunction is easy; the clauses of F aG 
are just the clauses of F and the clauses of G. Disjunction, on the other 
hand, is harder. From the identity 

(a a b) v (c a d) = (a v c) a (a v d) a (b v c) a (b v d) 

we see that the clauses of F vG are obtained by forming the cross-product 
of their individual clause sets. So although the size of F aG is at most the 
sum of the sizes of F and G, the size of F vG may be as large as the product 
of their sizes. 

N egation is even worse; in the worst case it produces an exponential 
blowup. Applying de M organ's laws to our sample expression, we get 

-i ((a v b) a (c v d)) 
= -i (a v b) v -i (c v d) 
= (-ia a -ib) v (-ic a -id) 

In general, theCNF of composite formulae is obtained according to these 
rules: 
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M [p c q] = V a,b. (a,b) g E[p] => (a,b) g E[q] 

M [p = q] = v a,b. (a,b) g E[p] «=> (a,b) e E[q] 

E [Id : T <-> T] = { (a,a) | a g C[T]} 

E [0] = { } 

E [Un : S <-> T] = { (a,b) | a g C[S] av b e C[T]} 

E[puq]=l (a,b) | (a,b) g E[p] v (a,b) e E[q]} 

E [p n q] = { (a,b) | (a,b) e E[p] a (a,b) e E[q]} 

E [p \ q] = { (a,b) | (a,b) e E[p] a (a,b) e E[q]} 

E [p ; q] = { (a,b) | 3c. (a,c) g E[p] a (c,b) e E[q]} 

E [p~] = { (a,b) | (b,a) g E[p]} 

E [p+] = the smallest x such that x;xc xa pcx 

E[s<:p]={(a,b)s E[p] | (a.unit) g E[s]} 

E [dom p] = { (a,unit) | 3b. (a,b) e E[p]} 

Figure 7: Semanticsof intermediate language 



[FaC] = [F]u[C] 

[FvC] ={fug |fG [F]Age [C]} 

[-.F] = {c c Vars(F) | V f g [F] . 3! x. x g f a -,x g f } 

12 Translation to Boolean Conjunctive Normal Form 

U nderstanding the penultimate step depends on understanding the final 
step, so we explain the latter first. The penultimate step involves no change 
of language its input isardational formula in DN F, and its output is an- 
other rdati on al formula in DN F. In thefinal step, each DN F dauseis 
translated into a boolean formula in CN F. 

A rdation value can be represented as a boolean matrix, with true in theith 
row and thejth column exactly when theith dement of the domain type is 
rdated to thejth dement of the range type. So a variable denoting a rdation 
can be represented as a matrix of boolean variables, and, in general, a rda- 
tional expression can be represented as a matrix of boolean formulae. It is 
easy to define a compositional translation that obtains the representation 
X[e] of a rdational expression efrom the representations of its parts. Rda- 
tional composition, for example, corresponds to matrix product: 

X[p ; q]u = v k (X[p], k a X[q] kj ) 
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Thefull set of translation rules appears in Figure 8. No rule for transitive 
closure appears; as we shall see, the penultimate step (described in the next 
section) eliminates it. 

For each elementary subformula, a single boolean formula is derived. Writ- 
ing B[F] for the boolean formula derived from relational formula F, we 
have, for example, 

B [p c q] = a, aj (X[p]u => X[q]u) 

which, in terms of graphs, simply says that a relation pis a subset of a rela- 
tion q when the presence of any edge in p implies its presence in q. Note 
how equalities and inequalities translate smoothly into CNF: each element 

X[pL contributes a clause. The number of clauses thus rises linearly with the 
number of elements (and thus quadratically with the scope), although the 
clauses themselves grow more rapidly. T his observation is a major motiva- 
tion for the choice of CNF. 

Since the relational formula has been converted to D N F, with each con- 
junct being regarded as a separate problem to solve, there are only two logi- 
cal operators on relational formulae: negation and conjunction. Each is 
translated directly: 

B[-,F] = -,B[F] 

B[F aC] = B[F] a B[C] 

Conjunction is well behaved: each new elementary relational formula adds a 
new set of clauses, so that the number of clauses in the final formula is lin- 
ear in the size of the specification. Negation, as we have seen, however, is a 
major problem, and we shall explain below how its effects are minimized. 
Fortunately, the D N F clauses derived from practical problems tend to in- 
volve few negated formulae (rarely more than one). 

We explained above (Section 10) how typing constraints are translated into 
elementary relational formulae, and subsequently have no special treatment. 
In our previous work [DJJ 96], in which we used binary decision diagrams 
to solve the satisfaction problem, wetook a different approach, in which the 
encoding of a variable exploits its type constraints. 

Consider representing a total function to a set of 4 elements. Its value, seen 
as a bit matrix, must have exactly one bit true in each row. If, in the en- 
coding of the variable, the row is represented as 4 separate boolean variables 

< bo, bi, b2, b3 > 

this constraint must be expressed as a side condition 

bovbi vb?v b3 

A bo => — it) 1 A -lb2A — lb3 

A bl =» -ibo A -lb2A — lb3 

A b2 => -ibo A -iblA — lb3 

A b3=> -ibo A -iblA — lb2 
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B [p c q] = a, aj (X[p]u => X[q]u 
B [p = q] = a, aj (X[p]u «. X[q]ij 
X[ld]ij = (i =j) 
X [0]ij = false 
X [Un]ij = true 
X[pu q]u = X[p]u v X[q]u 
X[pn q]ij = X[p]u a X[q]u 
X [p \ q]u = X[p]u a -,X[q],j 
X [p ; q]u = vk X[p]ik a X[q]kj 
X [p~]u = X[pL, 
X[s<:p] IJ =X[p] IJ AX[s],o 
X [dom p] i0 = vk X[p]ik 



Figure 8: Translation from relational to boolean form 



Since each row in the matrix represents one of 4 possible values, only two 
bool ean vari abl es sh ou I d be n ecessary. V i ewi n g th e pai r of vari abl es b b x as a 
binary number, we can instead represent the row like this 

< -ibo a -ibi, -ibo a bi, bo A-ibi, bo a bi> 

in which theith entry is the assertion that the binary number b b 1 denotes 
the integer i. This encoding reduces the number of boolean variables re- 
quired from n to logn, and dispenses with side conditions. It applies 
widely, since not only functions but also scalars (which are treated as sin- 
gleton sets) can be encoded in this manner. 

In our BDD method, which was very sensitive to the number of variables, 
this gave a dramatic improvement in performance. But for the current 
method, these more sophisticated en codings perform considerably worse 
than simple encodings. In CN F, each entry in a row such as that shown 
above will consist of two clauses rather than one. This small difference is 
amplified by disjunction. 

Consider, for example, translating the composition of two relational vari- 
ables in a scope of k (that is, in which all domain and range types contain k 
elements). Each entry in the resulting matrix isthe result of a disjunction of 
k terms. In the simple encoding, each term consists of two singleton clauses, 
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so the entry can have 2 clauses. In the more sophisticated encoding, each 
term consists of (2 log k) singleton clauses, so the entry is a factor of (log k) 
larger. 

These calculations are borne out by our experiments. We implemented both 
encodings. The clever encoding not only brought no improvement, but in 
many cases caused the formula to outgrow available memory so rapidly that 
the formula could not be generated at all. 

At a lower level, a crucial consideration is how the C N F formula is repre- 
sented and whether simplifications are applied during translation. If a for- 
mula contains a clause and one of its subsets, the clause can be discarded; 
this is known assubsumption and follows from the fact that any model of F 
is also a model of F v G. Eliminating redundant clauses early on can have 
an enormous effect on the size of intermediate formulae. 

ur prototype uses a trie- based representation developed by Zhang and 
Stickel [ZS94]. Using tries naturally eliminates some redundancy- since 
literals in clauses are lexically ordered, and prefixes are shared, it is easy to 
ensure that a clause never appears with one of its prefixes. The trie also sup- 
ports a simple and efficient implementation of the Davis-Putnam satisfi- 
ability algorithm [DP60]. 

A huge performance gain is obtained by negation caching. A direct imple- 
mentation of the translation rules will sometimes cause the negation of a 
formula to be negated. Consider, for example, translating 

t = P ; q 

where p and q are relational variables. Each element of the matrix repre- 
senting the composition is a disjunction 

v k E[p],k a E[q]kj 

which, in CNF, will require 2 k clauses of 2 literals each. Representing an 
equality formula causes negation of boolean formulae on both sides 

x = F 

= (x ^ F) a (F ^ x) 
= (-ix v F) a (-iF v x) 

So the negation of these elements will be required. Directly negating an 
element formula causes a second blowup, so a naive translation will result in 
a huge formula. But the negation of the element formula is its dual 

Ak E[p]ik v E[q]kj 

and thisformula hasa small CNF representation: k clauses of 2 literals. 
W hen the element formula is computed, the compiler therefore computes 
its negation at the same time, and cachesit; when thenegation is later re- 
quired, the cached formula is used, and no computation is performed. Ad- 
ditionally, when ever a formula's negation is computed, the original formula 
is cached as its negation, so that no formula is negated twice. 
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13 Introduction of Temporary Variables 

We now turn to the phase that precedes the final one. It involves a simple 
manipulation of the intermediate language formula, designed to minimize 
the insidious effects of disjunction when the boolean formu la is subse- 
quent! y generated. 

This manipulation is nothing more than the introduction of fresh variables 
to replace relational subexpressions. Recall that the relational formula is in 
disjunctive normal form, each clause of which istreated separately. Suppose 
we havea formula that containsthesubexpression e, Without changing the 
meaning of the clause, we can replace e by a fresh variable v, and add to the 
clause the equality v =e. By maintaining a set of replaced expressions, we 
avoid introducing unnecessary new variables; if e is to be replaced in another 
context, the same variable v is used. This brings the standard benefit of 
common subexpression elimination: each subexpression is only translated 
once. But its primary motivation isthat introducing new variables can have 
a dramatic effect on the size of the final boolean formula. 

D ecisions about where to introduce variables are currently made according 
to some simple heuristics that seem to work well in practice. Although they 
seem plausible from a theoretical point of view, we have not shown them to 
be optimal, and it is likely they could be improved considerably. 

A disjunction of k boolean terms each with m clauses can result in a formula 
of size m . Variables are introduced when either m or k is large. We shall 
consider the cases in order of increasing importance. 

• The least dramatic case, but onethat nevertheless merits variable intro- 
duction, arises when each element of the resulting matrix is obtained by 
combining, with disjunction, an element from each of two matrices. In 
translating the union expression puq, we must therefore ensure that 
elements of the matrices resulting from translating p and q do not con- 
tain many clauses. Note that if p and q are relational variables, the ele- 
ments of X[puq] will still only contain a single clause. Composition 
and intersection, on the other hand, always create elements with multi- 
ple clauses. So our heuristic is to replace any expression that appears in 

a union expression that is itself a composition or an intersection expres- 
sion. 

• A similar issue arises at the elementary formula level. Translatingpcq 
also involves an element-wise disjunction, so we replace either p or q 
with a variable when both are expressions involving composition or in- 
tersection. 

• Translating relational composition gives riseto a disjunction of k terms, 
where k is the length of a row or column (ie, the scope). Each of these 
terms is itself the result of a conjunction, so composition is always ex- 
pensive. All subexpressions therefore, unless trivial (a variable or the 
transpose of a variable), are replaced by variables when appearing in a 
composition expression. 
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The most dramatic effect of disjunction arises for negated formulae. Con- 
sider, for example, the elementary formula 

wherep is some relational expression. This translates to a disjunction of k 
terms for a scope of k. In practice, unless p is a variable, the translation is 
usually infeasible. So for any negated formula, we replace the expressions on 
both sides with variables. In this case, the result is a formula with just one 
clause, but for other negated formulae the result is usually still large. The 
translation of 

->peq 

for example, has 2 to the power k clauses when both p and q are variables. 
For any scope above 3, this is infeasible, so this case is given special treat- 
ment (see Section 15). 

14 Transitive Closure 

Translating transitive closure presents some special problems. The transitive 
closure of a relation p, p+, is the small est relation r that includes p 

Per 

and is transitive 

r;rcr 

and can be computed by the series 

pu(p;p)u(p;p;p)u... 

Since p must be homogeneous, we can view it as a graph with one node for 
each element of the domain type of p, and an edge from node a to nodeb 
whenever p relatesa to b. Two nodes are associated by (p ; p) if there isa 
path of two edges from one to the other; by (p ; p; p) if there is a path of 
three edges, and so on; and by the closure if there is a path of any length 
between them. 

Computing the closure of a relation can thus be viewed as constructing 
paths in such a graph; in each step we compute a set of longer paths, and 
stop when we reach thefixpoint in which no path can be lengthened. H ow 
many steps might this take? If there are n nodes in the graph, a pair of nodes 
can either be connected with a path of length n or less, or not at all. It fol- 
lows that a simple iterative computation will require at most n steps, each 
involving a union and on average n/2 compositions. 

A more efficient way to translate closure is by the series: 

po = p 

Pi+1 = (Pi ; Pi) u p, 

Since any path of length no greater than 2k can be decomposed into two 
paths each of length no greater than k, it follows by induction that the ith 
approximation in this series will associate nodes that are connected by a 
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path of at most 2 edges. In this case, however, we will reach convergence in 
log n steps. This technique is known in model checking [BC492] as iterative 
squaring. 

One way to encode closure is to apply the translation rules for composition 
and union on thefly, translating the approximations p,. For exactly the rea- 
sons explained above (in Section 13), this will not generally be feasible: the 
unions lead to disjunctions of increasingly large formulae. So rather than 
using the series to evaluate the closure in boolean form, we use it to expand 
the closure expression syntactically. By performing this unwinding just prior 
to the stage in which variable introduction occurs, the effects of the dis- 
junctions are mitigated as for any other complex expression. 

Although this works well and is easy to implement, it does have one unde- 
sirable con sequence. The compilation becomes scope dependent in an ear- 
lier phase. Without closure, only the final translation to a boolean formula 
depends on the scope; now variable introduction becomes dependent too. 
In practice this is a minor annoyance, since the bulk of the compilation 
time is in thefinal phase. 

15 Symmetry Breaking 

For relational formulae involving only the set operations (union, intersec- 
tion and difference), the boolean formula grows only with k 2 for a scope of 
k. Composition, unfortunately, introduces a factor of 2 k . But far worse is 
the effect of certain negations: the formula 

is equivalent to 

vu -i E[p]u «=> E[q]u 

which results in a disjunction of k 2 terms, resulting in a boolean formula of 
2 tothek 2 dauses. Generating such a formula is infeasiblefor k >4. 

Such formulae arise primarily in two places. Operations often have precon- 
ditions that assert that a scalar is not in a set; this becomes an inequality on 
relations, but of dimension lxk, so the blowup is no worse than for a 
composition. M ore seriously, it is common to assert that an operation leaves 
a state component unchanged. T his gives a formula like 

OP A p' * P 

where op is the specification of the operation. A similar situation arises for a 
claim that an operation preserves an invariant that one relation isasubsetof 
another. 

T o address this problem, we apply some ideas from our previous work on 
symmetry [J D J 96, JJ D 97]. As we have shown, the models of relational for- 
mulae are permutation invariant: given a model of a formula, the assignment 
that results from permuting the atoms of the underlying universe will also 
be a model. Consider now a model of the formula 
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F a p * q 

in which for some particular values of i andj, 

-i E[p]u <=> E[q]u 

Applying the permutation that mapsi and j both to 0, we obtain a model in 
which 

-i E[p]oo «=> E[q]oo 

is true. We can therefore replace the disjunction 

vu -i E[p]u «* E[q]u 

by the single term 

-i E[p]oo <=> E[q]oo 

which, if p and q are variables, reduces the boolean formula to a single 
clause! 

T his argument has some subtleties. I f p is a homogeneous relation, its indi- 
ces cannot be permuted independently. Consequently, wehaveto indudea 
diagonal and an off-diagonal element. In general, as we plan to explain in a 
forthcoming paper, more than one negated equality (or inequality) can be 
reduced in this way, so long as each reduction exploits permutation of a 
different type. The prototype tool ranks the negated subformulae according 
to their severity, and then allocates symmetry breaking reductions from the 
most to the least severe, making sure never to break symmetry on the same 
type twice. Fortunately, there is usually only one negated subformulaon full 
relations, so the method works remarkably well. 

Negative equalities can also be translated into disjunctions that are handled 
separately, in the same manner as top-level disjunctions. The formula 

is equivalent to 

(-i p c q) v (-i q c p) 

The negated inequality 

-■peq 
can then be rewritten as 

pn(Un \q)#{} 

which can be simplified with variable introduction to 

t = pn(Un \ q) 

thusdiminating subsequent translation steps that would involve any more 
than elementwise operations on the boolean matrices. Problematic elemen- 
tary formulae that cannot be handled by symmetry breaking (because all 
types have been 'consumed') might be handled in this way. 
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16 Solving the Boolean Formula 

We have experimented with two solvers. We wrote a Davis-Putnam solver 
[DP60] using Zhang and Stickel's trie- based representation of formulae 
[ZS94] in J ava as part of the prototype. W e also wrote code to generate in- 
put files for Selman and Kautz'sWalkSAT solver [SKC 94], a descendant of 
GSAT [SLM92]. 

The two solvers are very different. WalkSAT, unlike Davis-Putnam, is in- 
complete: it may fail to find a satisfying assignment even though one exists. 
Also, because it starts from a random assignment, WalkSAT cannot be 
made to produce the simplest solutions first; in our Davis-Putnam imple- 
mentation, by favoring false over true in the case splitting step, we are able 
to bias the solver towards small relations. n the other hand, WalkSAT can 
handle much larger problems. We found that Davis-Putnam often stops 
working when the number of boolean variables exceeds a few hundred. 
WalkSAT, on the other hand, is so fast that the time it takes to solve the 
formula is invariably dominated by the time the compiler took to construct 
it. 

We have not found the incompleteness of WalkSAT to be a problem: we 
have yet to come across a problem that we believed had a solution but 
which WalkSAT failed to find. 

Both methods have a desirable performance property. When there is a solu- 
tion, it tends to be found very quickly; when there isn't, the solver can run 
for a very longtime. The engine underlying our previous implementation of 
N itpick [JJD97] did not have this property: in many cases, successful and 
unsuccessful searches took roughly the same amount of time (within a fac- 
tor of 2 to 10). Of course we would I ike the solver to work fast whatever the 
outcome, but if forced to pick, a very uneven distribution biased towards 
yielding solutions is, in practice, much better. 

17 Performance results 

Some performance results for a variety of specfications are shown in Table 
1; the specifications are reproduced, mainly in full, in the Appendix. The 
first two exam pies are toy benchmarks; Phone is the specification of Figurel 
(but for a different claim, invB_ preserved) and Finder is a specification of the 
directory structure of the M acintosh Finder. 

Style is a specification of the paragraph style hierarchy of M icrosoft Word, 
described in detail in [JD96a]. 

Allocate is a simplified fragment of a railway interlocking specification writ- 
ten in Z by Praxis UK PLC. T he performance figures are for the claim Al- 
locSafe2. 

Mobile IP is a specification of a draft version of a mobile internet protocol 
for IPv6, written by an undergraduate at Carnegie M dlon [JNW97, Ng97]. 
The performance figures are for the claim loc_update_OK, which exposed a 
flaw in the protocol. 
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Table 1 isto be interpreted as follows. Thecolumn marked Casesgivesthe 
number of clauses in theDN F representation of the claim; Formulae gives 
the maximum number of relational formulae in each clause. In the analysis 
of Style, for which there were 12 clauses, a model was always found in the 
first clause; the other columns refer to this clause alone. 

The columns marked Varsand Clauses give the number of boolean variables 
and dausesin theemitted formula; Translate and Solve give the times to 
perform the translation and solve the boolean formula. All formulae were 
solved using WalkSAT, except when D P appears in parentheses after the 
solving time; for these, the built in Davis-Putnam solver was sufficient (ie, 
found a solution in less than 30s). All timings were obtained using Sun- 
Soft's just-in-time compiler, running under Windows NT on a Pentium 
133M H z processor with 64M B of memory. All times are wall clock times; 
no attempt was made to get precise numbers for times less than 1 second. 

Thefinal column gives the time taken by the explicit version of Nitpick, 
coded in C and running on a M acintosh with a 66M H z PowerPC 601 
processor and 24M B of RAM . Since this machine is perhaps 3 times slower 
than the Windows machine, the solving times for the new method should 
be multiplied by 3. (The translation times do not need the same adjust- 
ment, because of a compensating discrepancy between J ava and C ). 

The entry?? indicates that a model was not found in a reasonable time; we 
set a bound of one hour. The explicit checker did find a model for M obile 
IP, but for a smaller scope in which different bounds were associated with 
different types. This scope could not be checked with the new method, be- 
cause the prototype currently allows only scope settings that give every type 
the same bound. 

As can be seen, the new method outperforms the old method in almost all 
cases. It seems likely that it will be able to handle much larger models. 
M oreover, the new method is much simpler to implement; our entire pro- 
totype is only about 6000 lines of Java code, of which almost half is con- 
cerned with front-end functionality (parsing and static checks). 

T he explicit method is barely able to handle the M obi Ie I P example, and 
cannot handle Allocate at all. Allocate is particularly well suited to the new 
method, because it involves several relations but few compositions. Finder, 
on the other hand, is biased towards the explicit checker; its relations are 
constrained to be functions, and transitive closure (which is no more expen- 
sive for the explicit checker than any other operator) appears several times in 
the formula. It is nevertheless surprising that WalkSAT takes so long to 
solve the scope 6 instance of Finder - it required about 760 thousand flips 
of boolean variables, distributed over 8 separate attempts from different, 
randomly generated starting assignments 

Tables 2 and 3 show the effects of negation caching and symmetry break- 
ing. In both, the italicized columns represent measurements taken without 
the optimization. N egation caching has a huge effect, increasing with the 
scope; in many cases, it reduces the final formula size by an order of mag- 
nitude. The scope 4 instance of Style is worth noting: the translation time, 
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but not the formula size is dramatically reduced. T his is probably because 
negation caching saves unnecessary computation, and reduces the size of 
many formulae generated in the course of the translation. 

Symmetry has a negligible effect on all examples except for Style, the only 
example whose formula involves negated equalities of relation-valued vari- 
ables. The italicized numbersin this table were obtained with symmetry 
breaking off, but negation caching on.Without symmetry, the formula for a 
scope of 5 cannot even be generated. 
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Example 
Phone 



Cases 



Formulae 
10 



Finder 



Style 



Allocate 



12 



Mobile IP 



47 



71 



41 



68 



Scope 



3 

4 

5 

6 

3 

4 

5 

6 

3 

4 

5 

3 

4 

5 

10 

3 

4 

5 



Vars 
66 
112 
170 
240 
273 
464 
705 
996 
408 
704 
1080 
192 
316 
470 
1690 
438 
760 
1170 



Clauses 

307 

842 

2159 

5413 

1364 

3500 

8483 

20779 

1864 

4385 

9977 

522 

931 

1473 

6693 

2436 

6548 

16536 



Translate 

0s 

Os 

Os 

Is 

Os 

Os 

Os 

9s 

Is 

2s 

6s 

Os 

Os 

Os 

6s 

Os 

3s 

8s 



Solve 
Os (DP) 
Os (DP) 
Os (DP) 
2s (DP) 
1 s (DP) 
Os 
3s 

2m, 33s 
6s (DP) 
Os 
5s 

1 s (DP) 
Os 
Os 
Os 
Os 
Os 
Os 



Explicit 
Os 
0.5s 
35s 
5m 
0.5s 
Is 
lis 

2m, 12s 
Is 
lis 

11m, 45s 
10s 

77 
77 
77 
77 
77 
7? 



Table 1: Performance compared to explicit method 
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Example 


Scope 


Vars 


Clauses 


Clauses 


Trans 


Trans 


Solve 


Solve 


Phone 


3 


66 


601 


313 


Is 


Os 


Os (DP) 


Os (DP) 


4 


112 


2808 


856 


Os 


Os 


Os (DP) 


Os (DP) 


5 


170 


12489 


2189 


31s 


0s 


Is (DP) 


Os (DP) 


6 


240 


52923 


5413 


6m, 12s 


Is 


5 s (DP) 


2s (DP) 


Finder 


3 


273 


1793 


1370 


Os 


Os 


Os 


1 s (DP) 


4 


464 


6935 


3500 + 


2s 


Os 


Os 


Os 


5 


705 


27831 


8483 + 


27s 


Os 


5s 


3s 


6 


996 


1 12635 


20866 


9m,32s 


9s 


? 


2m, 33s 


Style 


3 


408 


2908 


2234 


Os 


Os 


6 s (DP) 


6s (DP) 


4 


704 


57377 


53495 


lm,51s 


17s* 


Os 


Os 


5 


1080 


7? 


77 


7? 


7? 


7? 


7? 


Mobile IP 


3 


438 


3330 


2439 


Is 


Os 


Os 


Os 


4 


760 


13242 


6608 


17s 


3s 


Os 


Os 


5 


1170 


52826 


16691 


2m, 56s 


9s 


Os 


Os 



Table 2: Effect of negation caching 
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Example 


Scope 


Vars 


Clauses 


Clauses 


Trans 


Trans 


Solve 


Solve 


Style 


3 


408 


2234 


1864 


Os 


0s 


2 s (DP) 


6s (DP) 


4 


704 


53495 


4385 


17s 


2s 


Os 


Os 


5 


1080 


7? 


9977 


7? 


6s 


7? 


5s 



Table 3: Effect of symmetry breaking 



18 Related Work 

ur previous method worked by explicit enumeration of relation values, 
with two principal mechanisms to prune the search: short circuiting, in 
which a partial assignment could be rejected by determining that any exten- 
sion to a full assignment would not yield a model [D J 96], and isomorph 
elimination, which exploited symmetriesin thesearch space to avoid the 
generation of a high proportion of the relation values [J D J 96, JJ D 97]. 

n most of our examples, the new boolean method performs better. I n 
particular, the explicit checker does badly when there are several variables 
representing relations that are not constrained to be functions, and for 
which there are few mutual constraints; in this case, short circuiting fares 
badly, and thesearch is often intractable. The explicit checker always prefers 
functionsto relations; the boolean checker, in contrast, prefers relations 
si nee there are then no side conditions. On the other hand, increasing the 
complexity of the formula itself tends to improve the performance of the 
explicit checker, but it has a detrimental effect on the boolean checker. The 
explicit checker can take advantage of equalities by eliminating variables; the 
boolean checker, in contrast, introduces variables to avoid complex expres- 
sionsand reduce translation time, and pays the price in solving time. For 
this reason, the explicit checker might be better as a simulator: if operations 
are expressed mostly constructively (with post-state variables equated to ex- 
pressions involving pre-state variables), it can explore the execution of ase- 
quence of operations with little extra cost. 

In his PhD thesis, Craig Damon is investigating bounded generation, anew 
pruning mechanism for the explicit checker that seems, from initial experi- 
ments, to be promising. It remainsto be seen how it will perform in com- 
parison to the boolean checker. 

We have experimented before with a boolean checker, representing boolean 
formulae not in CNF but with ordered binary decision diagrams (BDDs) 
[D JJ 96]. Although that method performed very well on some small exam- 
ples, it did not appear to scale. Unlike CN F, a BDD is canonical, so trans- 
lation cannot be separated from solving; if the formula has no models, it 
must be the formula false. Translation into BDD scan take vast amounts of 
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memory, and offers no discount for finding only some models, since the 
final BDD represents all models. The BDD -based checker also suffered 
from the well known unpredictability of BDD s; a small change in the vari- 
able ordering might have a dramatic effect, and problems that looked alike 
were often not equally hard to solve. The canonicity of BDD sis essential in 
the context of model checking, because it allows detection of fixed points. 
But for our problem, canonicity is unnecessary and its cost is not warranted. 

T he remarkable success of the stochastic solver G SAT [SLM 92] and its de- 
scendants has made boolean translation attractivein other domains too. 
The closest application to ours is in planning, where the problem of finding 
apian that satisfies a set of constraints is reduced to finding a model of a 
boolean formula [KS96, EM W 97]. The planning problem istechnically 
closer to the model checking problem than to our problem: namely finding 
a sequence of transitions in a state machine that leads to a state satisfying a 
given property (in planning, the goal, and in model checking, the negation 
of the invariant). Thefocuson data structures rather than on transition se- 
quences makes our compilation process rather different from those em- 
ployed in planning. 

19 Future Work 

19.1 Algorithms and Data Structures 

The trie representation of CNF is reasonably compact- typically a third 
smaller than a representation without sharing of subclauses- and, because 
of the ordering of variables, efficiently manipulated. The trie structure 
eliminates some redundancy, but not all: a clause may appear with a sub- 
clause if the subclause is not a prefix. W e performed some experiments to 
determine what proportion of clauses held in the trie are redundant; it ap- 
pears to be around 30% for large tries. It might bepossibleto eliminate 
more redundancy without too much additional computation, perhaps by 
using a different data structure such as a suffix tree. 

19.2 Language Extensions 

Several features would add nothing in expressive power but would make N P 
an easier language to use. 

Quantifiers over scalar variables would relieve the burden of encoding all 
constraints with relational operators alone. One common idiom that calls 
for quantifiers (or perhaps a dual of the composition operator) arises from 
an assertion that would be written with quantifiers thus: 

forall x, y, z. (x -> y) in p and (y -> z) in q => (x -> z) in r 

To encode thisin relational operators, we rewrite with negations 

not exist x, y, z. (x -> y) in p and (y -> z) in q and not (x -> z) in r 

and then translate negation using complementation: 

p;q&(Un \ r)={} 

The purely relational version is often - as here- terse, elegant and obscure. 



35 



An abstraction mechanism for generic fundi onsand constraints would simplify 
specifications by factoring out complex idioms. Tree structure, for example, 
arises frequently; rather than axiomatizing each tree structure anew, the 
specifier might writeTree(p) to assert that a relation p mapping nodes to 
their parents describes a tree, with the predicate!" ree previously defined: 

Tree (p) = (Fun(p) and Acyclic(p) and One(Roots(p))) 
Acylic(p) = (p+& Id ={}) 
Roots (p) = (ran p \ dom p) 
One (s) = (Fun(Un :> s)) 
Fun (p) = (p~ ; p c Id) 

T ernary relations are not common, but are clumsy to encode as binary rela- 
tions and should be supported directly. A ternary relation r on A x B x C is 
probably best treated curried, so that r.a denotes a relation on B x C. 

Integers would add expressive power. Subtraction, addition and comparison 
alone would allow a sequence of elements of type T to be modelled more 
naturally as a function from a prefix of the naturals to T, where currently we 
are forced to represent the sequence more abstractly as an ordering of buck- 
ets that contain values. Indexing of sequences would simply bean instance 
of function application; concatenation would be provided explicitly. H ow 
to handle the semantics of integer addition over a finite scope is not clear. 
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Appendix: Benchmark Specifications 

Phone 

[Ph, Num] 

Switch = [ 
Called: Ph <-> Num 
const Net: Num -> Ph 
Conns: Ph <-> Ph 

I 

Conns = Called ; Net 
] 

Join (p: Ph; n: Num) = [ 
Switch 

I 

p in dom (Called) 

not (n in ran Called) 

Called' = Called U {p -> n} 
] 

invB = [Switch | (dom Conns) & (ran Conns) = {}] 
invC = [Switch | fun (Conns-)] 

lnvB_preserved (p: Ph; n: Num) :: [Switch | Join(p,n) and invB => invB'] 
lnvC_preserved (p: Ph; n: Num) :: [Switch | Ooin(p,n) and invC) =>invC] 

Finder 

[OBJ] 

Finder = [ 

const drive, trash: OBJ 

const files, folders: set OBJ 

dir, links: OBJ -> OBJ 

trashed, aliases: set OBJ 

I 

{drive, trash} <= folders \ dom dir 

ran dir <= folders 

trashed = dir — h .{trash} 

not drive in trashed U {trash} 

aliases <= files 

aliases = dom links 

links+& Id ={} 

files & folders = {} 

files U folders = OBJ 
1 

Move (x, to: OBJ) = [ 
Finder 

I 
x not in dir*.{to} 
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dir' = dir (+) {x -> ((links* ;> aliases).to)} 
links' = links 



TrashingWorks (x, to: OBJ) :: [Finder | 
Move (x, to) 

and to in trashed U {trash} 
= > x in trashed' 



Style 

[style, format] 

Tree = [ 
based : style -> style 
const normal : set style 
I 

normal & dom based = {} 
ran based \ normal <= dom based 
based+& Id = {} 
1 

Sheet = [ 
Tree 
delta, assoc : style -> format 

I 

normal <: assoc = normal <: delta 

normal <; assoc = normal <; ((based ; assoc) (+) delta) 

1 

ChgParent (s, from, to : style) = [ 
Sheet 
I 

s in dom based and from = based. s 
based' = based (+) {s -> to} 
assoc' = assoc 
{s} <; delta = {s} <; delta' 
assoc. to = assoc. from => delta' = delta 
1 

Xi ()= [const Sheet] 

Claim (s, from, to : style) :: 
[Style | ChgParent (s, from, to) ; ChgParent (s, to, from) => Xi()] 

Allocate 

[USER, RESOURCE] 

Bookings = [ 
reservedBy : RESOURCE -> USER 
pending, granted, free : set RESOURCE 
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reserved : set RESOURCE 
I 

reserved = dom reservedBy 

pending & granted & free = {} 

pending & free = {} 

granted & free = {} 

pending U granted U free = RESOURCE 
] 

Resources = [ 

open, closed : set RESOURCE 

const overlap, incons, excludes : RESOURCE <-> RESOURCE 

excluded : set RESOURCE 
I 

overlap~ = overlap and overlap & Id = {} 

incons~ = incons and incons & Id = {} 

excludes = incons U overlap 

incons. open <= closed 

excluded = excludes. open 

open & closed = {} 

open U closed = RESOURCE 



Users = [ 

usedBy : RESOURCE -> USER 

used : set RESOURCE 
I 

used = dom usedBy 



Allocate (r : RESOURCE; u : USER) = [ 

Resources Users Bookings 
I 

r in (pending & open) \ (excludes. reserved) 

{r -> u} <= reservedBy 

granted' = granted U {r} 

reservedBy' = reservedBy 

usedBy' = usedBy U {r -> u} 



AllocSafeO (r : RESOURCE; u : USER) :: [ 

Resources Users Bookings 
I 

Allocate (r, u) and (excludes. reserved & reserved = {}) 
= > excludes. reserved' & reserved' = {} 



AllocSafel (r : RESOURCE; u : USER) :: [ 
Resources Users Bookings 

I 
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Allocate (r, u) and (excluded & granted= {}) 
= >excluded' & granted' = {} 



AllocSafe2 (r : RESOURCE; u : USER) :: [ 
Resources Users Bookings 

I 

Allocate (r, u) and (incons.used & used = {}) 
= > (incons.used' & used' = {}) 



AllocSafe3 (r : RESOURCE; u : USER) :: [ 

Resources Users Bookings 
I 

Allocate (r, u) and (incons U overlap). used & used = {} 
= > (incons U overlap). used' & used' = {} 
] 

Mobile IP 

[HOST, MSC, TS] 

net = [ 
router: HOST 
cached: set HOST 
subh: set HOST 
clock: TS 

caches: HOST -> HOST 
cache_exp_time: HOST -> TS 
updates: set MSC 
to, from, where: MSC -> HOST 
send_time, exp_time: MSC -> TS 
const precedes: TS -> TS 
const before: TS <-> TS 



I 



dom to = updates 

dom from = updates 

dom where = updates 

dom send_time = updates 

dom exp_time = updates 

dom cache_exp_time = dom caches 

exp_time <= send_time; precedes + 

caches & Id = {} 

(from; from~) & (to; to~) & (send_time; send_time~) <= Id 

(from-; to) & Id = {} 

/* axiomatize the time ordering as a total order */ 
/* for now, make do with weaker constraint */ 
before = precedes + 
before & Id = {} 
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mh.arrive (h:HOST; m:MSC; t:TS) = [net | 
not router = h 
router' = h 
not m in updates 
t in (before.{clock}) 
clock' in (before.{clock}) 
subh <= cached 
cached' = subh 

cache_exp_time' = (cached' <: cache_exp_time) :> (before.{clock'}) 
caches' = dom(cache_exp_time') <: caches 
updates' = updates U {m} 
send_time' = send_time U {m -> clock} 
exp_time' = exp_time U {m -> t} 
to' = to U {m -> router} 
from' = from U {m -> h} 
where' = where U {m -> h} 



update_arrival (m:MSG) = [net | 

clock' in before.{clock} 

subh <= cached 

cached' = {to.m} U subh 

cache_exp_time' = (cached' <: (cache_exp_time (+){to.m -> exp_time.m})) :> 
(before.{clock'}) 

caches' = dom (cache_exp_time') <: (caches (+) {to.m -> where. m}) 

router' = router 

updates' = updates 

to' = to 

from' = from 

where' = where 

send_time' = send_time 

exp_time' = exp_time 



acyclic_caches = [net | caches+ & Id = {}] 

host_move_OK (h:HOST; m:MSC; t:TS) :: 

[net | acyclic_caches and mh_arrive (h, m, t) => acyclic_caches'] 

loc_update_OK(m:MSC) :: 

[net | acyclic_caches and update_arrival (m) => acyclic_caches'] 
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